Инструкция по смене паролей для системных учетных записей¶

Введение¶

Данная инструкция предназначена для предоставления информации о безопасном и корректном механизме смены паролей для системных учетных записей, используемых для корректной работы ALD Pro.

Область применения¶

Данная инструкция в полном объеме актуальна для домена под управлением ALD Pro версий 2.4.0 и выше, в котором на контроллерах домена и на других компьютерах с развернутыми подсистемами установлена операционная система (ОС) Astra Linux 1.7.4 или выше.

Термины и определения¶

Контроллер домена (КД) - сервер, который контролирует определенную область компьютерной сети, а также управляет доступом к различным ресурсам внутри этой области.
Служба каталога - средство иерархического представления ресурсов и информации об этих ресурсах.
Lightweight Directory Access Protocol (LDAP) - протокол прикладного уровня для доступа к службе каталогов, разработанный как облегчённый вариант протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей.
Free Identity Policy and Audit (FreeIPA) - открытое программное обеспечение, специализированная служба каталогов, предназначенная для создания в ОС Linux среды, позволяющей централизованно управлять аутентификацией пользователей, устанавливать политики доступа и аудита. Функционал FreeIPA подобен Active Directory, используемому в Windows.
389 Directory Server (389 DS) - служба каталогов уровня предприятия с открытым исходным кодом, предназначенная для централизованного управления доступом к ресурсам на множестве сетевых серверов.
Системная учетная запись (Системная УЗ) - В рамках данного документа под системными учетными записями во FreeIPA понимаются записи службы каталога, находящиеся в ветке cn=sysaccounts,cn=ipa,dc={domain_component}, а также специальные учетные записи, используемые ALD Pro для выполнения различных действий, не связанных с действиями пользователей системы. Записи из ветки cn=sysaccounts,cn=ipa,dc={domain_component} в FreeIPA управляют внутренними процессами и сервисами самой FreeIPA. Эти учетные записи не предназначены для обычных пользователей и обеспечивают функционирование различных сервисов и ролей внутри инфраструктуры, поддерживая безопасность и доступ в системе на уровне домена. Служат для управления служебными процессами и настройками безопасности, такими как конфигурация политик доступа или обслуживание инфраструктуры. Эти учетные записи не имеют привилегий для интерактивного входа в систему и не отображаются в командных интерфейсах FreeIPA, предназначенных для работы с пользователями.
Secure SHell (SSH) - Сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений.
Samba - Пакет программ, которые позволяют обращаться к сетевым дискам и принтерам на различных операционных системах по протоколу SMB/CIFS.
Domain Name System (DNS) - система доменных имён — это иерархическая децентрализованная система именования для ресурсов, подключённых к глобальной сети, которая ведёт список доменных имён вместе с их числовыми IP-адресами или местонахождениями.
Kerberos - сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними. Kerberos выполняет аутентификацию в качестве службы аутентификации доверенной третьей стороны, используя криптографический ключ. Kerberos построен на криптографии симметричных ключей и требует наличия центра распределения ключей. Расширения Kerberos могут обеспечить использование криптографии с открытым ключом на определённых этапах аутентификации.
Internet Protocol (IP) - маршрутизируемый протокол сетевого уровня стека TCP/IP.
Transmission Control Protocol (TCP) - протокол Управления Передачей - протокол сети интернет, который позволяет двум хостам создать соединение и обмениваться потоками данных. TCP гарантирует доставку данных и пакетов в том же порядке, в котором они были отправлены.
IP-адрес - уникальный числовой идентификатор устройства в компьютерной сети, работающей по протоколу IP.
Аccess control instruction (ACI) - инструкция управления доступом, которая определяет, кто или что может получать доступ к объекту (программе, процессу или файлу), и какие именно операции разрешено или запрещено выполнять субъекту (пользователю, группе пользователей).

Общий алгоритм смены паролей для системных учетных записей в 389 DS¶

Общее описание¶

В проекте FreeIPA используются системные учетные записи для различных целей, связанных с управлением внутренними сервисами, выполнением различных служебных операций, управлением инфраструктурой безопасности и аутентификацией. Эти учетные записи могут храниться в ветке cn=sysaccounts,cn=etc базы данных LDAP, которая управляется с помощью одного из компонентов FreeIPA - 389 Directory Server (389 DS). Эта ветка является частью структуры службы каталога, и ее основная роль заключается в хранении специальных учетных записей, которые необходимы для работы сервисов и выполнения административных задач. Часть этих учетных записей создается автоматически при установке и настройке FreeIPA, а другая часть создается и настраивается теми программными продуктами, которые используют FreeIPA (например, ALD Pro). Данные учетные записи не предназначены для обычного использования конечными пользователями. Также в ряде случаев системные учетные записи могут храниться и в других ветках 389 DS.

Смена пароля для системных учетных записей должна проводиться очень осторожно, поскольку эти учетные записи используются как самой службой FreeIPA, так внешними приложениями или сервисами для доступа к базе данных LDAP или другим сервисам в инфраструктуре. Это важно, поскольку нужно убедиться, что после смены пароля внешние приложения продолжат корректно работать.

Идентификация учетных записей и их использования¶

Перед сменой пароля необходимо определить, какие внешние приложения или сервисы используют эти системные учетные записи. Это могут быть:

различные сервисы из состава ALD Pro;
сервис репликации между серверами FreeIPA;
система для управления сертификатами;
программы для интеграции с Active Directory;
службы аутентификации через LDAP или Kerberos;
другие сервисы, которые подключаются под системными учетными записями и используют LDAP для своих нужд и функционируют в текущей инфраструктуре.

Подготовка к смене паролей для системных учетных записей 389 DS¶

Перед сменой пароля выполнить следующие действия:

убедиться, что у есть резервные копии конфигураций всех внешних приложений, которые используют эти учетные записи;
оповестить ответственных за приложения или службы, использующие эти учетные записи, о предстоящей смене пароля, чтобы была возможность подготовиться к обновлению пароля в своих конфигурациях (для сервисов и приложений, которые используют службу каталогов, но не входят в комплект поставки ALD Pro);
проверить настройки конфигурации в самих внешних приложениях, чтобы удостовериться, что они могут работать с новыми паролями.

Смена пароля конкретной системной учетной записи 389 DS с помощью команды ldapmodify¶

Смена пароля конкретной системной учетной записи 389 DS с помощью команды ldapmodify происходит по следующему алгоритму:

Авторизация во FreeIPA: для изменения пароля системной учетной записи 389 DS выполнить вход в систему FreeIPA с правами администратора (например, с учетной записью Directory Manager или под admin с помощью получения билета kerberos после установки ALD Pro).

Для изменения пароля системной учетной записи использовать команду ldapmodify. Например, если требуется сменить пароль для учетной записи sudo, выполнить команду:

Исходный код 1 Смена пароля УЗ sudo¶

ldapmodify -x -D "cn=Directory Manager" -W <<EOF
dn: uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: newpassword
EOF

где newpassword - строка с паролем, которая должна отвечать требованиям настроенных политик паролей.

Обновление конфигурации внешних приложений¶

После того как пароли для системных учетных записей в службе каталога были изменены, необходимо обновить их в конфигурациях внешних приложений, которые используют эти учетные записи для подключения к LDAP или другим сервисам.

В зависимости от того, какие внешние сервисы используют системные учетные записи, нужно будет обновить конфигурацию подключения в каждом приложении:

Для сервисов, использующих LDAP, таких как приложения, которые подключаются к 389 DS из состава FreeIPA для аутентификации, обновить файл конфигурации LDAP, где прописаны учетные данные (или тот контейнер, откуда эти сервисы получают данные для аутентификации в LDAP). Внести изменения в конфигурационные файлы (контейнеры) каждого такого сервиса.
Для Kerberos: если системные учетные записи используются для аутентификации через Kerberos, обновить принципал Kerberos. Например:

kadmin.local -q "changepw some_kerberos_service",

если это сервисный принципал, то, возможно, потребуется перезапуск служб, использующих Kerberos.

Если внешнее приложение использует учетную запись для других сервисов, например, для генерации сертификатов или управления политиками, необходимо убедиться, что пароль обновлен в конфигурации этих сервисов. Например:

для ipa-certmaster: обновить конфигурационные файлы и убедиться, что процесс управления сертификатами будет продолжать работать;
для ipa-otpd: проверить, что изменения не повлияют на систему One-Time Password.

Перезапуск служб и тестирование работоспособности¶

После изменения пароля и обновления конфигураций приложений необходимо:

Перезапустить все сервисы, которые используют эти учетные записи. Это может включать:

FreeIPA (ipa сервисы)
389 DS (служба LDAP)
Службы репликации
Cервисы, использующие Kerberos или Sudo
Другие связанные сервисы и приложения

Провести тестирование, чтобы убедиться, что все сервисы, использующие эти учетные записи, продолжают функционировать правильно. Это можно сделать, проверив подключение к LDAP, а также тестируя репликацию, аутентификацию пользователей и доступ к другим сервисам.

Мониторинг дальнейшей работы сервисов, использующих в своей работе системные учетные записи FreeIPA¶

После смены паролей и обновления конфигураций важно мониторить систему, чтобы убедиться, что нет сбоев или ошибок, связанных с неправильными учетными данными. Рекомендуется протестировать изменения в контролируемой среде перед их внедрением в рабочую инфраструктуру. Кроме того, необходимо иметь четкий план восстановления, чтобы оперативно устранить возможные ошибки в случае возникновения непредвиденных обстоятельств.

Cмена паролей для системных учетных записей, используемых ALD Pro, при работе с одной версией продукта (по расписанию или требованиям безопасности)¶

Общее описание¶

В проекте ALD Pro используются системные учетные записи для различных служб и для различных целей, связанных с управлением внутренними сервисами, выполнением служебных операций, управлением инфраструктурой безопасности и аутентификацией. Аутентификационные и авторизационные данные для этих учетных записей хранятся в конфигурационных файлах ALD Pro, в ветке cn=sysaccounts,cn=etc базы данных LDAP, которая управляется с помощью одного из компонентов FreeIPA - 389 Directory Server (389 DS). Эти учетные записи создаются автоматически при установке и настройке ALD Pro (также при настройке интеграции с RuPost) и не предназначены для обычного использования конечными пользователями.

Доступ системных учетных записей из ветки cn=sysaccounts,cn=etc к данным службы каталога настраивается с помощью ACI и механизма ролей/привилегий/разрешений FreeIPA, которые определяют, какие операции могут быть выполнены на уровне данных LDAP. Предустановленные в ALD Pro системные учетные записи настроены с такими ограничениями, которые обеспечивают безопасность и контролируют доступ к критически важным данным, обеспечивая правильную работу тех прикладных сервисов, которые подключаются к службе каталога под данными учетными записями. Для просмотра всех таких записей можно обратиться к вышеуказанной ветке базы данных службы каталога.

Смена пароля для системных учетных записей должна проводиться крайне осторожно, поскольку эти учетные записи используются внешними приложениями или сервисами для доступа к базе данных LDAP или другим сервисам в инфраструктуре ALD Pro. Важно убедиться, что после смены пароля все компоненты ALD Pro и другие внешние приложения инфраструктуры продолжат корректно работать.

Смена паролей для системных учетных записей, которые не хранятся в базе данных службы каталога, а используются для работы с другими внешними относительно ALD Pro продуктами (например, Zabbix, PostgreSQL), описана ниже в этом разделе.

Обобщенный алгоритм смены пароля системных учетных записей, которые использует ALD Pro¶

Алгоритм включает в себя следующие последовательные этапы:

Убедиться в том, что все экземпляры 389 DS связаны между собой с помощью механизмов репликации данных и что данные отношения репликации функционируют корректно (особенно, если они настроены НЕ с помощью ALD Pro);
Смена паролей в 389 DS для всех системных УЗ (необходимых для смены согласно регламенту или требований), ожидание успешной репликации данных паролей этих УЗ на остальные реплики (или смена паролей для этих учетных записей на всех репликах самостоятельно, если репликация данных между экземплярами 389 DS не настроена или не работает корректно);
Смена паролей в файлах настроек ALD Pro на каждом КД (при необходимости для конкретной системной УЗ из 389 DS);
Смена паролей для системных УЗ в атрибутах envvar на КД;
Смена паролей в файле настроек ALD Pro на подсистемах (при необходимости, если эти подсистемы используют указанную системную УЗ для работы);
Смена паролей для системных УЗ в атрибутах envvar на необходимых подсистемах;
Смена паролей учетных записей в PostgreSQL, необходимых ALD Pro;
Перезапуск необходимых сервисов после смены паролей.

Файлы, которые используются для получения аутентификационных данных в различных сервисах или подсистемах ALD Pro (символ «←» означает символическую ссылку):

Портал управления ALD Pro на каждом КД - /etc/aldpro/core.env ← /opt/rbta/ad/mgmtportal/api/core/.env
Справочный Центр ALD Pro на каждом КД - /etc/aldpro/help.env ← /opt/rbta/aldpro/mp/api/help-center/.env
RabbitMQ на каждом КД - /etc/aldpro/services.env ← /opt/rbta/aldpro/mp/api/services/.env
Syncer на каждом КД (при установке syncer) - /etc/aldpro/syncer.env ← /opt/rbta/aldpro/syncer/.env
Сервер репозиториев ПО на каждом развернутом сервере репозиториев - /etc/aldpro/repo.env ← /opt/rbta/aldpro/repo/.env
Сервер установки ОС по сети на каждом развернутом сервере установки ОС по сети - /etc/aldpro/os.env ← /opt/rbta/aldpro/os/.env
На каждом КД для формирования основного pillar при установке с нуля и при обновлении версии продукта на новую версию формируется файл с паролями /etc/aldpro-salt/stack/passwords.yml. Этот файл либо формируется путем получения данных из службы каталогов (различные атрибуты envvar из записей КД из ветки cn=fqdn_DC,cn=computers,cn=accounts, а также из атрибутов envvar подсистемы сервера репозиториев ПО cn=sr,cn=services,cn=aldpro,cn=etc и подсистемы установки ОС по сети cn=pxe,cn=services,cn=aldpro,cn=etc), либо путем генерации новых паролей при установке ALD Pro. Помимо этого, из этого файла регулярно получается пароль для учетной записи saltstackservice для обеспечения работы службы pkiproxy на том КД, на котором эта служба установлена и работает.

Проверка репликации данных между экземплярами 389 Directory Server¶

Перед началом смены паролей для системных учетных записей важно убедиться, что репликация данных работает корректно. Проверить состояние репликации с помощью следующих команд с выводом информации о состоянии в формате json:

dsconf -j <INSTANCE> replication status --suffix <SUFFIX>

где <INSTANCE> - имя экземпляра инстанса службы каталога, а <SUFFIX> - доменный суффикс. Для получения списка <INSTANCE> можно воспользоваться командой dsctl -l

Например:

dsconf -j EXAMPLE-RU replication status --suffix dc=example,dc=ru

Если в результате команды выдается json со следующей парой ключ-значение:

{
"desc": "No object exists given the filter criteria..."
}

это означает, что репликация в данный момент не найдена или некорректно заданы условия для команды. Необходимо убедиться в том, что в портале управления ALD Pro в подразделе Управление доменом → Сайты и службы на вкладке «Соглашения о репликации» присутствуют данные о репликации.

Проверить состояние репликации между серверами можно с помощью утилиты ds-replcheck:

ds-replcheck online -D "cn=Directory Manager" -m ldap://dc-1.ald.company.local:389 -r ldap://dc-2.ald.company.local:389 -b dc=ald,dc=company,dc=local

В случае отсутствия команды dsconf на конкретном КД, следует установить ее следующей командой:

sudo apt-get install python3-lib389

Список используемых системных УЗ для работы ALD Pro¶

К системным учетным записям, используемым для обеспечения корректной и бесперебойной работы ALD Pro, относятся следующие записи (по умолчанию при установке продукта находятся в файлах конфигурации ALD Pro):

core - УЗ, используемая для подключения к СУБД PostgreSQL на каждом КД.
async - УЗ, используемая для подключения к СУБД PostgreSQL на каждом КД для работы с данными асинхронной очереди задач RabbitMQ.
syncer - УЗ, используемая для подключения к СУБД PostgreSQL на каждом КД для работы с данными syncer.
helpcenter - УЗ, используемая для подключения к СУБД PostgreSQL для работы справочного центра ALD Pro на каждом КД.
repo - УЗ, используемая для подключения к СУБД PostgreSQL на каждом сервере репозиториев.
osinstall - УЗ, используемая для подключения к СУБД PostgreSQL на каждом сервере установки ОС по сети.
common_env - УЗ, которая используется для просмотра атрибутов envar в записях о каждом КД или подсистеме (где эти атрибуты присутствуют). В LDAP находится в записи uid=commonenv,cn=sysaccounts,cn=etc,dc=example,dc=ru.
orgunitservice - УЗ, используемая ALD Pro для работы с подразделениями (ou). В LDAP находится в записи uid=orgunitservice,cn=sysaccounts,cn=etc,dc=example,dc=ru.
trustsservice - УЗ, используемая ALD Pro для работы с доверительными отношениями между доменами (trusts). В LDAP находится в записи uid=trustsservice,cn=sysaccounts,cn=etc,dc=example,dc=ru.
saltstackservice - УЗ, используемая ALD Pro для работы напрямую с базой данных службы каталога (для выполнения различных служебных операций). Также используется для выполнения команд FreeIPA или для работы API FreeIPA, когда это необходимо для выполнения служебных операций в ALD Pro. В LDAP находится в записи uid=saltstackservice,cn=sysaccounts,cn=etc,dc=example,dc=ru.
roleservice - УЗ, используемая ALD Pro для работы с различными механизмами гранулярного управления доступом на основе ролей (roles/privileges/permissions/ACI). В LDAP находится в записи uid=roleservice,cn=sysaccounts,cn=etc,dc=example,dc=ru.
syncer/dc01.{domain_component}@{DOMAIN_COMPONENT} - УЗ, используемая ALD Pro для работы компонента syncer (если он был установлен) с данными в 389 DS. В LDAP находится в записи uid=syncer/dc01 {domain_component}@{DOMAIN_COMPONENT},cn=sysaccounts,cn=etc,dc=example,dc=ru.
aldpro_srv_zabbix - УЗ, используемая для подключения к основному серверу Zabbix в домене под управлением ALD Pro. В LDAP находится в записи uid=aldpro_srv_zabbix,cn=sysaccounts,cn=etc,dc=example,dc=ru.

Смена паролей в 389 DS для всех системных УЗ, которые использует ALD Pro¶

В этом разделе описана замена паролей для всех системных учетных записей, расположенных в cn=sysaccounts,cn=etc,dc=example,dc=ru. После выполнения изменений необходимо дождаться успешной репликации данных на все контроллеры домена в системе или, при отсутствии репликации между экземплярами 389 DS, выполнить изменения вручную на каждом контроллере домена.

Важно

Изменение пароля для системной учетной записи в 389 DS приведет к прекращению работы всех сервисов, использующих данную учетную запись, до обновления их конфигураций с новым паролем и последующего перезапуска. В связи с этим, после введения изменений из данного раздела, некоторые функции ALD Pro могут стать недоступны до корректировки паролей в конфигурационных файлах продукта и перезапуска сервера Apache. Помимо этого, для стабильной работы ряда функций потребуется обновление пароля в атрибутах envvar для контроллеров домена и подсистем.

Системные учетные записи, создаваемые и эксплуатируемые ALD Pro в 389 DS, включают:

uid=aldpro_srv_zabbix,cn=sysaccounts,cn=etc,dc=example,dc=ru
uid=commonenv,cn=sysaccounts,cn=etc,dc=example,dc=ru
uid=orgunitservice,cn=sysaccounts,cn=etc,dc=example,dc=ru
uid=trustsservice,cn=sysaccounts,cn=etc,dc=example,dc=ru
uid=saltstackservice,cn=sysaccounts,cn=etc,dc=example,dc=ru
uid=roleservice,cn=sysaccounts,cn=etc,dc=example,dc=ru
uid=syncer/dc01.example.ru@EXAMPLE.RU,cn=sysaccounts,cn=etc,dc=example,dc=ru

Изменение пароля учетной записи uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=ru представлено в разделе Смена пароля конкретной системной учетной записи 389 DS с помощью команды ldapmodify.

Для изменения паролей каждой учетной записи следует воспользоваться утилитой ipa-ldap-updater, предназначенной для синхронизации и обновления LDAP-записей в системе IPA. В качестве параметра необходимо передать файл в формате .ldif, содержащий информацию о DN (Distinguished Name) учетной записи, для которой производится изменение пароля, а также сам обновленный пароль:

Исходный код 2 Пример .ldif для смены пароля aldpro_srv_zabbix¶

dn: uid=aldpro_srv_zabbix,cn=sysaccounts,cn=etc,dc=example,dc=ru
only:userPassword:{zabbix_password}

В первой строке указан dn записи, для которой необходимо внести изменения. Во второй строке содержится наименование атрибута, в котором хранится пароль для этой записи, а также строка с обновленным паролем. При выполнении этой команды 389 DS создаст хеш для предоставленной строки пароля, используя алгоритм, указанный в настройках LDAP-каталога, и запишет его в соответствующий атрибут.

Кроме того, в подобном файле .ldif можно задать пароли для всех системных учетных записей, используемых в ALD Pro, находящихся в ветке cn=sysaccounts,cn=etc. Например, следующим образом:

Исходный код 3 Пример .ldif для изменения паролей УЗ cn=sysaccounts,cn=etc,dc=example,dc=ru¶

dn: uid=aldpro_srv_zabbix,cn=sysaccounts,cn=etc,dc=example,dc=ru
only:userPassword:{aldpro_srv_zabbix_password_string}

dn: uid=commonenv,cn=sysaccounts,cn=etc,dc=example,dc=ru
only:userPassword:{commonenv_password_string}

dn: uid=orgunitservice,cn=sysaccounts,cn=etc,dc=example,dc=ru
only:userPassword:{orgunitsservice_password_string}

dn: uid=trustsservice,cn=sysaccounts,cn=etc,dc=example,dc=ru
only:userPassword:{trustsservice_password_string}

dn: uid=saltstackservice,cn=sysaccounts,cn=etc,dc=example,dc=ru
only:userPassword:{saltstackservice_password_string}

dn: uid=roleservice,cn=sysaccounts,cn=etc,dc=example,dc=ru
only:userPassword:{roleservice_password_string}

dn: uid=syncer/dc01.example.ru@EXAMPLE.RU,cn=sysaccounts,cn=etc,dc=example,dc=ru //необходимо подставить свой fqdn и свой REALM
only:userPassword:{syncer_password_string}

Обновить LDAP-записи системных учетных записей:

ipa-ldap-updater <change_sysaccounts_password>.ldif

где <change_sysaccounts_password> обозначает файл, содержащий необходимые изменения, представленные выше.

Смена паролей в файлах настроек ALD Pro на каждом КД (при необходимости для конкретной системной УЗ из 389 DS)¶

На этом этапе следует обновить пароли в конфигурационных файлах ALD Pro, где хранятся данные для аутентификации, на каждом контроллере домена для всех системных учетных записей, пароли которых были изменены на предыдущем этапе.

На последующих этапах будет проводиться смена паролей в базе данных, поэтому рекомендуется сохранить первоначальные пароли (/etc/aldpro/*.env), в особенности для УЗ:

core: /etc/aldpro/core.env
async: /etc/aldpro/services.env
syncer: /etc/aldpro/core.env
helpcenter: в/etc/aldpro/help.env
zabbix: /etc/aldpro/core.env

При изменении пароля любой системной учетной записи в 389 DS необходимо внести изменения в файл /etc/aldpro/core.env. В этом файле содержатся учетные данные для различных сервисов ALD Pro, которые подключаются к 389 DS на каждом из контроллеров домена. Данные представлены в виде строк, например, {saltstackservice_password_string} обозначает строку пароля для служебной учетной записи saltstackservice. Ниже перечислены все необходимые переменные, в которых требуется произвести изменения при модификации пароля для системных УЗ в 389 DS.

Переменные в /etc/aldpro/core.env:

LDAP_PASSWORD={saltstackservice_password_string}
APPLDAP_IPA_PASSWORD={saltstackservice_password_string}
SAMBA_PASSWORD={saltstackservice_password_string}
REGISTERSERVICE_PASSWORD={saltstackservice_password_string}
DISCOVER_PASSWORD={saltstackservice_password_string}
ZABBIX_PSW={aldpro_srv_zabbix_password_string}
ROLESERVICE_PASSWORD={roleservice_password_string}
ENV_PASSWORD={commonenv_password_string}
ORGUNITS_MOVE_SYSACCOUNT_PASSWORD={orgunitsservice_password_string}
TRUSTS_SYSACCOUNT_PASSWORD={trustsservice_password_string}
SYNCER_ALDPRO_PASSWD={syncer_password_string}

При изменении строки пароля системной учетной записи, необходимо обновить пароль во всех переменных, где использовалась УЗ. Таким образом, изменение пароля для системной УЗ uid=saltstackservice,cn=sysaccounts,cn=etc,dc=example,dc=ru из подраздела Смена паролей в 389 DS для всех системных УЗ, которые использует ALD Pro затронет переменные LDAP_PASSWORD, APPLDAP_IPA_PASSWORD, SAMBA_PASSWORD, REGISTERSERVICE_PASSWORD, DISCOVER_PASSWORD.

Примечание

ENV_PASSWORD={commonenv_password_string}: дополнительно необходимо актуализировать в /etc/aldpro/help.env

SYNCER_ALDPRO_PASSWD={syncer_password_string}: в случае установки службы syncer на любом КД и изменении пароля системной УЗ uid=syncer/dc01.example.ru@EXAMPLE.RU,cn=sysaccounts,cn=etc,dc=example,dc=ru необходимо дополнительно зайти по ssh на первый контроллер домена и под пользователем postgres выполнить команду:

psql syncer -U postgres -c "UPDATE schema_options.auth set password = 'syncer_password_string' where \"user\"='syncer/dc01.example.ru@EXAMPLE.RU';"

где syncer_password_string - строка нового пароля от УЗ uid=syncer/dc01.example.ru@EXAMPLE.RU,cn=sysaccounts,cn=etc,dc=example,dc=ru в 389 Directory Server.

После внесения изменений, необходимо перезапустить сервис Apache с помощью команды:

systemctl restart apache2

Все указанные действия должны быть выполнены на каждом контроллере домена, так как сервисы ALD Pro работают на всех контроллерах.

Смена пароля для системных УЗ, которые не создаются в 389 DS¶

Системные учетные записи, которые не хранятся в cn=sysaccounts,cn=etc,dc=example,dc=ru, в основном используются для обеспечения работы сервисов и PostgreSQL (см. подраздел Список используемых системных УЗ для работы ALD Pro). Для изменения пароля системной учетной записи core, необходимой для работы с PostgreSQL, требуется обновить пароль в конфигурационном файле /etc/aldpro/core.env на каждом контроллере домена для переменной:

CORE_DB_PASSWORD={core_password_string}

Для изменения пароля системной учетной записи core, необходимой для работы с RabbitMQ, требуется обновить пароль в конфигурационном файле /etc/aldpro/core.env на каждом контроллере домена для переменной:

CELERY_RABBIT_PASSWORD={core_rabbitmq_password_string}

Для изменения пароля системной учетной записи syncer, необходимой для работы с PostgreSQL, требуется обновить пароль в конфигурационном файле /etc/aldpro/core.env и /etc/aldpro/syncer.env на каждом контроллере домена для переменной:

SYNCER_DB_PASSWORD={syncer_db_password_string}

Для изменения пароля системной учетной записи zabbix, необходимой для работы с PostgreSQL, требуется обновить пароль в конфигурационном файле /etc/aldpro/core.env на каждом контроллере домена для переменной:

ZABBIX_DB_PSW={zabbix_db_password_string}

Для изменения пароля учетной записи helpcenter, которая используется для работы справочного центра с PostgreSQL, необходимо обновить пароль в конфигурационном файле /etc/aldpro/help.env на каждом контроллере домена для переменной:

HELPCENTER_DB_PASSWORD={helpcenter_db_password_string}

Для изменения пароля учетной записи async, которая используется для работы с PostgreSQL, необходимо обновить пароль в конфигурационном файле /etc/aldpro/services.env на каждом контроллере домена (КД) для переменной:

ASYNC_DB_PASSWORD={async_password_string}

Для изменения пароля учетной записи async, которая используется для работы с RabbitMQ, необходимо обновить пароль в конфигурационном файле /etc/aldpro/services.env на каждом контроллере домена (КД) для переменной:

ASYNC_RABBIT_PASSWORD={async_rabbitmq_password_string}

Для данных учетных записей необходимо дополнительно обновить пароль в PostgreSQL или RabbitMQ, в зависимости от изменяемой УЗ, а также в некоторых файлах конфигурации на подсистемах для УЗ zabbix, что описано в последующих шагах.

В конфигурационных файлах ALD Pro, указанных выше, содержатся переменные SECRET_KEY, представляющие собой ключи для Django, которые автоматически создаются модулями ALD Pro. Если возникает необходимость замены ключа, следует воспользоваться командой:

aldpro-salt-call django_secret_key.generate

В файлах .env также хранится переменная NOTIFICATIONS_BASE64_PASSWORD, необходимая для отображения иконки статуса «Связь установлена» на главной странице портала управления. Для генерации NOTIFICATIONS_BASE64_PASSWORD используется команда:

aldpro-salt-call hashutil.base64_encodestring $(openssl rand -hex 28)

Новый пароль указывается в файлах /etc/aldpro/services.env и /etc/aldpro/core.env. Генерация производится на каждом КД.

Смена пароля для системных УЗ в RabbitMQ¶

В процессе обновления пароля для системных учетных записей core или async, использующихся в функционировании RabbitMQ, необходимо провести актуализацию паролей непосредственно в системе управления очередями на КД. Для этого следует воспользоваться следующей командой:

rabbitmqctl change_password <username> <new_password>

где <username> обозначает соответствующую учетную запись (либо core, либо async), а <new_password> — это новый пароль, определенный в конфигурационных файлах .env ранее (например, {core_rabbitmq_password_string} или {async_rabbitmq_password_string}).

После внесения изменений, необходимо перезапустить сервисы Apache и RabbitMQ с помощью команды:

systemctl restart apache2 rabbitmq-server

Смена паролей для системных УЗ в атрибутах envvar на КД¶

При выполнении задач, связанных с созданием реплик контроллеров домена, развёртыванием доменных подсистем и обновлением до новой версии ALD Pro, используются атрибуты envvar в записях ветки cn={DC_FQDN},cn=masters,cn=ipa,cn=etc. После изменения паролей системных учетных записей требуется обновить значения этих атрибутов для всех записей контроллеров домена.

Автоматизировать обновление атрибутов можно с помощью утилиты migrateenv, предназначенной для миграции параметров из файла .env в LDAP.

Активировать виртуальное окружение:

source /opt/rbta/venvs/aldpro-common/bin/activate

Запустить утилиту migrateenv. Например:

python -m aldpro_core_env.migrateenv --path /opt/rbta/ad/mgmtportal/api/core/.env --service dc --subsystem dc01.example.com --write_user=uid=admin,cn=users,cn=accounts --write_password=12345678 --read_user=uid=admin,cn=users,cn=accounts --read_password=12345678

Параметры migrateenv:

–path: Путь до файла .env (включая имя файла). (Обязательный аргумент),
–service: Целевой сервис для взаимодействия. (Обязательный аргумент),
–subsystem: Целевой сервис для взаимодействия. (Обязательный аргумент),
–write_user: DN (без суффикса) пользователя, с правами на добавление envvar,
–write_password: Пароль от write_user,
–read_user: DN (без суффикса) пользователя, с правами на чтение envvar,
–read_password: Пароль от read_user,
–save_old: Сохранить ли старые envvar

Выйти из виртуального окружения с помощью команды:

deactivate

Перезапустить Apache с помощью команды:

systemctl restart apache2

Смена паролей в файле настроек ALD Pro на подсистемах¶

Смена паролей в файлах настроек ALD Pro¶

На последующих этапах будет проводиться смена паролей в базе данных, поэтому рекомендуется сохранить первоначальные пароли (/etc/aldpro/*.env), в особенности для УЗ:

repo: /etc/aldpro/repo.env
osinstall: /etc/aldpro/os.env

После выполнения предыдущих этапов и изменении пароля ENV_PASSWORD в файлах переменных core.env и help.env для УЗ uid=commonenv,cn=sysaccounts,cn=etc,dc=example,dc=ru, требуется обновить пароль в переменной ENV_PASSWORD, расположенной в файлах /etc/aldpro/repo.env и /etc/aldpro/os.env на каждом сервере репозиториев ПО и установки ОС по сети соответственно.

В отношении учетной записи saltstackservice также необходимо провести обновление пароля в переменной DISCOVER_PASSWORD, которая находится в /etc/aldpro/os.env на каждом сервере установки ОС по сети.

При изменении пароля для учетной записи aldpro_srv_zabbix, необходимо обновить пароль в файле /etc/systemd/system/aldpro-zabbix-discovering-systemd.conf на сервере мониторинга:

ALDPRO_ZABBIX_PASSWORD=»{aldpro_srv_zabbix_password_string}»

При изменении пароля учетной записи zabbix (подраздел Смена пароля для системных УЗ, которые не создаются в 389 DS), необходимо обновить соответствующие настройки в конфигурационных файлах на сервере мониторинга. Это включает внесение изменений в следующие файлы:

/etc/zabbix/zabbix_server.conf.bak:
- Параметр DBPassword следует установить на новое значение пароля: {zabbix_db_password_string}
/etc/zabbix/zabbix.conf.php:
- Обновить запись для параметра базы данных на новое значение: $DB['PASSWORD'] = '{zabbix_db_password_string}';
/etc/zabbix/zabbix_server.conf
- Внести изменения для переменной DBPassword={zabbix_db_password_string}

Для изменения пароля учетной записи repo (изменение пароля для данной УЗ на предыдущих этапах не проводилось), используемой для работы с PostgreSQL, необходимо внести изменения в следующие переменные файла /etc/aldpro/repo.env на каждом сервере репозиториев ПО для переменной:

DB_PASSWORD={repo_password_string}

Для изменения пароля учетной записи repo (изменение пароля для данной УЗ на предыдущих этапах не проводилось), используемой для работы с RabbitMQ, необходимо внести изменения в следующие переменные файла /etc/aldpro/repo.env на каждом сервере репозиториев ПО для переменной:

CELERY_RABBIT_PASSWORD={repo_rabbitmq_password_string}

Для изменения пароля учетной записи os (изменение пароля для данной УЗ на предыдущих этапах не проводилось), используемой для работы с PostgreSQL, необходимо внести изменения в следующие переменные файла /etc/aldpro/os.env``на каждом сервере установки ОС по сети для переменной:

POSTGRES_PASSWORD={os_password_string}

Для изменения пароля учетной записи os (изменение пароля для данной УЗ на предыдущих этапах не проводилось), используемой для работы с RabbitMQ, необходимо внести изменения в следующие переменные файла /etc/aldpro/os.env на каждом сервере установки ОС по сети для переменной:

CELERY_RABBIT_PASSWORD={os_rabbitmq_password_string}

В конфигурационных файлах ALD Pro на подсистемах (/etc/aldpro/repo.env и /etc/aldpro/os.env) также содержатся переменные SECRET_KEY, представляющие собой ключи для Django, которые автоматически создаются модулями ALD Pro. Если возникает необходимость замены ключа, следует воспользоваться командой:

aldpro-salt-call django_secret_key.generate

Смена пароля для системных УЗ в RabbitMQ на подсистемах¶

В процессе обновления пароля для системных учетных записей os или repo, использующихся в функционировании RabbitMQ, необходимо провести актуализацию паролей непосредственно в системе управления очередями на тех подсистемах, где требуется смена пароля. Для этого следует воспользоваться следующей командой:

rabbitmqctl change_password <username> <new_password>

где <username> обозначает соответствующую учетную запись (либо os, либо repo), а <new_password> — это новый пароль, определенный в конфигурационных файлах .env ранее ( {os_rabbitmq_password_string} или {repo_rabbitmq_password_string}).

После внесения изменений, необходимо перезапустить сервисы Apache и RabbitMQ с помощью команды:

systemctl restart apache2 rabbitmq-server

Смена паролей для системных УЗ в атрибутах envvar на подсистемах¶

Для работы некоторых подсистем, а также обновления на новую версию ALD Pro используются атрибуты envvar в записях веток cn={FQDN_OSINSTALL},cn=pxe,cn=services,cn=aldpro,cn=etc (для подсистемы установки ОС по сети) и cn={FQDN_REPOSUBSYSTEM},cn=sr,cn=services,cn=aldpro,cn=etc (для подсистемы репозиториев ПО). После процедуры смены паролей для системных учетных записей необходимо внести новые пароли в корректные атрибуты envvar для всех записей подсистем. Для этого необходимо выполнить на указанных подсистемах следующие команды.

Активировать виртуальное окружение:

source /opt/rbta/venvs/aldpro-common/bin/activate

Обновление envvar выполняется с помощью утилиты migrateenv. Информация о необходимых параметрах представлена в разделе Смена паролей для системных УЗ в атрибутах envvar на КД.

Пример для подсистемы установки ОС по сети:

python -m aldpro_core_env.migrateenv --path /etc/aldpro/os.env --service pxe --subsystem os01.example.com --write_user=uid=admin,cn=users,cn=accounts --write_password=12345678 --read_user=uid=admin,cn=users,cn=accounts --read_password=12345678

Пример для подсистемы репозиториев ПО:

python -m aldpro_core_env.migrateenv --path /etc/aldpro/repo.env --service repo --subsystem repo01.example.com --write_user=uid=admin,cn=users,cn=accounts --write_password=12345678 --read_user=uid=admin,cn=users,cn=accounts --read_password=12345678

Перезапустить Apache с помощью команды:

systemctl restart apache2

Смена пароля в файле конфигурации доменных паролей¶

На каждом контроллере домена для создания основного pillar, как при первоначальной установке, так и при обновлении продукта до новой версии, производится формирование файла с паролями /etc/aldpro-salt/stack/passwords.yml. Этот файл регулярно используется для получения пароля учетной записи saltstackservice, что необходимо для функционирования службы pkiproxy. При изменении пароля для системной УЗ saltstackservice необходимо дополнительно поменять пароль в файле /etc/aldpro-salt/stack/passwords.yml. Для выполнения этого действия требуется внести строку с паролем ({saltstackservice_password_string}) от uid=saltstackservice,cn=sysaccounts,cn=etc,dc=example,dc=ru в переменную "salt: {saltstackservice_password_string}".

Файл passwords.yml формируется на каждом сервере, выполняющем какую-либо из ролей в домене. Определить перечень таких серверов:

ldapsearch -b "cn=computers,cn=accounts,$SUFFIX" "(rbtaSubsystemRole=*)" dn

где $SUFFIX — это соответствующие компоненты доменного имени.

Для обеспечения и поддержания актуальности используемых паролей, могут быть обновлены и остальные упоминаемые пароли УЗ. Переменные в /`etc/aldpro-salt/stack/passwords.yml:

core: {core_password_string}
async: {async_password_string}
helpcenter: {helpcenter_db_password_string}
salt: {saltstackservice_password_string}
syncer: {syncer_db_password_string}
zabbbix: {aldpro_srv_zabbix_password_string}
zabbix_db: {zabbix_db_password_string}
common_env: {commonenv_password_string}
orgunits_service: {orgunitsservice_password_string}
trusts_service: {trustsservice_password_string}
os: {os_password_string}
repo: {repo_password_string}
role: {roleservice_password_string}
syncer_passwd: {syncer_password_string}

Значение соответствует введеному паролю для переменных из подразделов выше.

Смена паролей для необходимых ALD Pro учетных записей в PostgreSQL¶

Для обновления пароля для учетных записей core, async, syncer (DB), helpcenter на КД и repo на сервере репозиториев, osinstall установки ОС по сети, zabbix на сервере мониторинга, необходимо выполнить его обновление в PostgreSQL согласно следующему алгоритму:

Перейти в интерактивную оболочку PostgreSQL, используя команду:

psql -U <user> -h localhost -d <dbname>

Где:

-U, –username=ИМЯ — имя учетной записи;
-d, –dbname=БД — имя базы данных для подключения.

Для подключения необходимо использовать изначальный пароль, что был сохранен на этапах Смена паролей в файлах настроек ALD Pro на каждом КД (при необходимости для конкретной системной УЗ из 389 DS) и Смена паролей в файле настроек ALD Pro на подсистемах. Необходимые данные для подключения указаны в соответствующих конфигурационных файлах:

core: выполнить cat /etc/aldpro/core.env | grep «CORE_DB» на КД,
async: выполнить cat /etc/aldpro/services.env | grep «ASYNC_DB» на КД,
syncer: выполнить cat /etc/aldpro/core.env | grep «SYNCER_DB» на КД,
helpcenter: выполнить cat /etc/aldpro/help.env | grep «HELPCENTER_DB» на КД,
repo: выполнить cat /etc/aldpro/repo.env | grep «DB» на сервере репозиториев,
osinstall: выполнить cat /etc/aldpro/os.env на сервере установки ОС по сети.
zabbix: выполнить cat /etc/zabbix/zabbix_server.conf | grep -v „#“ | grep DB на сервере мониторинга.

Внутри интерактивной оболочки запустить утилиту \password:

\password <user>

где <user> — учетная запись, для которой производится смена пароля.

Примечание

При изменении пароля для учетной записи uid=saltstackservice,cn=sysaccounts,cn=etc,dc=example,dc=ru на предыдущих этапах, необходимо обновить пароль в базе данных zabbix. Внутри интерактивной оболочки выполнить следующий SQL-запрос:

UPDATE config SET ldap_bind_password = '{saltstackservice_password_string}'  where configid='1';

Выполнить выход из интерактивной оболочки с помощью \q.

Для обновления пароля учетной записи aldpro_srv_zabbix в PostgreSQL следует воспользоваться пользовательским интерфейсом Zabbix, доступным по URL: https://<сервер_мониторинга>/zabbix/ (например, https://mon01.ald.company.ru/zabbix/), авторизовавшись с помощью первоначальных данных, полученных через команду cat /etc/aldpro/core.env | grep "ZABBIX". В разделе интерфейса «User settings» имеется функция «Change password», которой необходимо воспользоваться для смены пароля УЗ:

Рис. 1. Интерфейс Zabbix

Альтернативным, но менее рекомендованным методом изменения пароля является его обновление непосредственно в базе данных. Необходимые для подключения данные можно найти в переменных DBName, DBUser, DBPassword с помощью команды: cat /etc/zabbix/zabbix_server.conf | grep -v '#' | grep DB:

psql -U zabbix -h localhost -d zabbix -c "UPDATE users SET passwd = '<new_password>' WHERE username = 'aldpro_srv_zabbix';"

где <new_password> - новый пароль в формате MD5.

При обновлении пароля учетных записей aldpro_srv_zabbix и/или saltstackservice, требуется обновить данные аутентификации LDAP в zabbix (https://<сервер_мониторинга>/zabbix/, учетные данные aldpro_srv_zabbix):

Рис. 2. Аутентификация Zabbix

Обновление пароля в Grafana¶

Grafana служит инструментом для визуализации данных, получаемых из Zabbix, позволяя представлять эти данные через дашборды в портале управления ALD Pro: Мониторинг → Витрины мониторинга домена.

В случае обновления пароля учетной записи aldpro_srv_zabbix, необходимо провести соответствующие изменения в конфигурации Grafana для обеспечения корректной интеграции с Zabbix. Выполнить следующие шаги для обновления данных подключения в Grafana:

Открыть веб-браузер и перейти на адрес интерфейса Grafana по URL: https://<сервер_мониторинга>:3000 (например, https://mon01.ald.company.ru:3000). Для доступа использовать УЗ admin и первоначальный пароль aldpro_srv_zabbix.
Перейти в раздел Configuration (Конфигурация) и выбрать пункт Data Sources (Источники данных). В списке источников данных выбрать конфигурацию, связанную с Zabbix. Полный путь до раздела: Home → Connections → Your → connections → Data sources → Zabbix.
В настройках источника данных найти поле, предназначенное для хранения пароля пользователя Zabbix. Ввести новый пароль учетной записи aldpro_srv_zabbix.
После обновления пароля проверить и подтвердить корректность остальных параметров подключения, таких как URL сервера, имя пользователя и другие, при необходимости. Нажать кнопку Save & Test (Сохранить и протестировать), чтобы проверить соединение с Zabbix и убедиться в правильности введённых данных.

Рис. 3. Смена пароля Grafana

Перезапуск затронутых сервисов ALD Pro и других приложений после смены паролей¶

После изменения пароля и обновления конфигураций приложений необходимо перезапустить:

FreeIPA (ipa сервисы)
389 DS (служба LDAP)
Службы репликации
Сервисы, использующие Kerberos или Sudo
Другие связанные сервисы и приложения

На каждом контроллере домена выполнить:

aldproctl restart

Для перезапуска репликации необходимо временно отключить соглашение о репликации:

dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt disable --suffix "dc=example,dc=com" example-agreement

Где example-agreement - наименование соглашения о репликации. Для получения необходимо выполнить команду:

dsconf -j <INSTANCE> replication status --suffix dc=example,dc=com

agmt-name будет соответствовать example-agreement. Повторно включить соглашение о репликации, чтобы установить обновление:

dsconf -D "cn=Directory Manager" ldap://server.example.com repl-agmt enable --suffix "dc=example,dc=com" example-agreement

Проверить статус репликации:

dsconf -D "cn=Directory Manager" ldap://supplier.example.com repl-agmt status --suffix "dc=example,dc=com" example-agreement

Дополнительно:

systemctl restart postgresql sssd zabbix-agent.service

На сервере установки ОС:

systemctl restart tftpd-hpa

На сервере мониторинга:

systemctl restart zabbix-agent.service

systemctl restart zabbix-server.service grafana-server.service

После смены пароля и перезапуска репликации убедиться, что синхронизация данных между репликами работает корректно. Например, создать произвольную запись (нового пользователя) на одном сервере и проверить, что эта же запись появилась на других репликах.

Также рекомендуется произвести перезапуск сторонних служб, не являющихся частью ALD Pro, которые задействовали системные учетные записи.

Заключение¶

После обновления паролей и конфигурационных файлов необходимо тщательно отслеживать работу системы, чтобы удостовериться в отсутствии сбоев или ошибок, связанных с некорректными учетными данными. Необходимо проанализировать журналы для выявления возможных ошибок аутентификации или отказов в подключении, что особенно важно для сервисов, функционирующих нерегулярно или преимущественно в фоновом режиме. Обратить внимание на время возникновения ошибок и сопоставить его с недавними изменениями в системе. Если возможно, временно вернуться к предыдущей версии конфигурации, чтобы стабилизировать работу служб и предотвратить дальнейшие сбои. Далее, повторно проверить все изменения конфигурации и учетных данных, включая базу данных (LDAP или PostgreSQL). Проверить текущее состояние и функционирование систем управления доступом и систем связанных с работой системных УЗ.